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An Apparatus and Method for Processing information from a Telephone 

Network 



Field of the Invention 
5 This invention relates to an apparatus and method for processing information 
from a telephone network, particularly, though not exclusively, to an apparatus 
and method for processing call record data from a telephone network having 
out-of-band signaling. 
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10 Backgroun d of the Invention 

In modern switched telecommunications systems (in particular, modern PSTNs) 
it has become common practice to provide two related but separate network 
infrastructures: a bearer or transmission network for carrying end-user voice and 
data traffic, and a signalling network for controlling the setup and release of 
m 1 5 bearer channels through the bearer network in accordance with control signals 

Q transferred through the signalling network (sometimes known as out-of-band 

signalling). In practice, such signalling networks comprise high-speed 
computers interconnected by signalling links; computer programs control the 
U| computers to provide a set of operational and signalling functions in accordance 

*£ 20 with a standardised protocol. One example of such a signalling protocol is the 

f : Signalling System No. 7 (SS7), whether as specified by the CCITT, ANSI, ETSI 

La (for GSM), Beflcore or similar body, such as a network being herein referred to 

Q as an SS7 network. The CCITT Signalling System Number 7 is specified in 

Recommendations QJ00 - Q.716 CCITT Volume Vl-Fascicle VL7, Geneva 
25 1 989, ISBN 92-61-0351 1 -6. SS7 networks are being extensively deployed for 
control of telephone and other data transmission networks and basically 
comprise various types of signalling points, namely, Signalling End Points 
(SEPs), for example an end office or local exchange, and Signalling Transfer 
Points (STPs) interconnected by signalling links, the SEPs being associated for 
30 example with respective Signalling Switching Points (SSPs) of the transmission 
network, and with Signalling Control Points (SCPs). 

As is known in connection with SS7 networks, signaling information is passed 
over the signaling links. In particular, the signaling information is used by a 
35 CDR Builder to generate a Call Detail Record (CDR) which can later be 

analyzed. For example, the CDRs can be analyzed by reference to a particular 
customer of a telecommunications company (telco) operating the SS7 system, 
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or certain types of data can be mined from Call Detail Records maintained by 
telcos in billing databases. 

The CDRs may be generated by an apparatus, such as the product developed 
by Agilent Technologies and known as "acceSS7". This apparatus consists of a 
CDR Builder, a CDR Agent and a Data Management Component (DMC).The 
CDR Builder monitors the signaling channels of the SS7 network and generates 
the CDRs, which are then passed via the CDR Agent to the DMC, where they 
are processed and correlated to provide a database of the records that can be 
viewed by interested parties, for example, telcos. An interface is provided to the 
databases so that the telcos can carry out various processing and analysis 
functions, for example, checking billing, checking that data is transferred 
correctly, checking for quality of service, etc. However, if it is required to carry 
out processing and analysis functions on other types of data records, for 
example Transaction Detail Records (TDRs), which can also be generated from 
an SS7 network, this would require a separate data processor programmed with 
different software, which would be expensive and inefficient to provide and to 
maintain. 

Brief Summary of the Invention 

The present invention therefore seeks to provide a method and apparatus for 
processing information from a telephone network, which overcomes, or at least 
reduces the above-mentioned problems of the prior art. 

Accordingly, in a first aspect, the invention provides an apparatus for processing 
data records, the apparatus comprising means for receiving data records of a 
plurality of different types, each type having a different predetermined format, a 
plurality of type-specific function libraries, each library having functions 
associated with each of the particular types of data record, means for receiving 
instructions indicative of the particular type(s) of data records to be received and 
indicative of which particular functions are to be performed on the data records 
to be received, means for reading the contents of the type-specific library(ies) 
associated with the particular type of data records to be received, means for 
processing received data records according to the particular functions to be 
performed, and an output for rendering the processed data records. 

In a preferred embodiment, at least one database is coupfed to the output for 
storing the processed data records. 
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According to a second aspect, there is provided a method of processing data 
records from a telephone network, the method comprising the steps of receiving 
instructions indicative of which particular type(s) of a plurality of different types 
5 of data records are to be processed, receiving instructions indicative of which 
particular functions are to be performed on the data records to be processed, 
reading the contents of at least one particular type-specific library of functions 
associated with the particular type(s) of data records to be processed, receiving 
data records of the particular type(s), processing the received data records 
10 according to the particular functions to be performed, and rendering the 

processed data records, wherein the first four steps above can be carried out in 
any order. 

Preferably, the particular functions to be performed on the data records to be 
pi 1 5 received include one or more common functions from a set of common 

Q functions. The set of common functions preferably includes one or more 

jjj functions that provide system management functions. 

if 

|fj The types of data records can include a Call Detail Record, a Transaction Detail 

M 20 Record, or a Service Detail Record. The data records can originate from, 
* example, a Signaling System No. 7 (SS7) network, a GSM network, an 

L Intelligent Network Application Part (INAP) network or an internet Protocol (IP) 

CI network. 

25 Brief Description of the Drawings 

One embodiment of the invention will now be more fully described, by way of 
example, with reference to the drawings, of which: 

FIG. 1 shows a block diagram of a system incorporating the apparatus 
according to one embodiment of the present invention; 
30 FIG. 2 shows a schematic flow chart of the operation of the apparatus 

shown in FIG, 1 ; and 

FIG. 3 shows schematically a software implementation of the operation of 
the apparatus of FIG. 1. 

35 Detailed Description of the Drawings 

Thus, FIG. 1 shows a Data Management Component (DMC) 1 according to an 
embodiment of the present invention. The DMC 1 has a first input for receiving 
data records from a record agent 2, which receives the call data records from a 
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record builder 3. The record builder 3 monitors a telephone network 4 and 
generates the call data records from the signaling data on the telephone 
network. In one exampfe, the telephone network is an SS7 network and the 
record agent 2 and the record builder 3 are conventional devices, such as those 
5 sold by Agilent Technologies and known as a acceSS7'\ 

The DMC 1 also has a second input coupled to an instruction builder 5, which is 
controlled by a user 6 to generate instructions to be passed to the DMC 1 . The 
two inputs to the DMC are connected to a processing device 7, which also has 
10 connections to a set of common functions 8 and to a plurality of function 
libraries 9-11, and a plurality of record stores 12-14, In essence, the 
processing device 7 receives instructions at the second input from the user 6 via 
the instruction builder 5 as to what type of call data records are to be received at 
the first input from the record agent 2. Depending on what type of call data 
1 5 records are to be received, the processing device 7 reads the contents of the 
appropriate function libraries 9 - 11 to a working memory in the processing 
Q device 7. The processing device 7 then determines, from instructions received 

from the user 6 via the instruction builder 5, which of the read functions and 
which of the functions from the set 8 of common functions are actually to be 
lj 20 used in processing the call data records to be received, and then carries out the 

processing of the call data records when they are received at the first input. 
H The processed call data records are then stored in the appropriate database(s) 

^ 12-14. The set 8 of common functions can also include functions that are 

£j[ used for management of the system, for example for managing the database 

C| 25 space. 

Li? 

Turning now to FIG. 2, the operation of the DMC 1 will be more fully described. 
The types of record to be used in a load (feed) operation and the operations to 
be performed within that feed are specified in a configuration file 15 that is 

30 generated by the user using the instruction builder, as described above. When 
the DMC is scheduled to run it reads the configuration file 15. At this early 
stage in the load the DMC determines, as shown at step 16, from the 
configuration file 15, which types of feeds (types of data records, such as CDR, 
TDR, GSM) are to be loaded. The DMC then reads (step 17) the required Type- 

35 Specific shared libraries chosen from all the available Type-Specific Libraries 
19, 20, 21 which contain the functions for each type of record. In this example, 
the configuration file specifies that the types of record that are to be received 
are CDR and GSM, which is a type of TDR record. Thus, once the CDR and 
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GSM function libraries 19, 20 have been loaded into the memory image of the 
DMC, the DMC obtains further information from the configuration file as to which 
operations are to be performed on each record in the relevant feeds. For 
example a CDR operation list may include Check, Translate, Complete 
5 Telephone Numbers, Correlate, Output. This information would typically be 
provided as a list for each feed in the configuration file. Other functions to be 
performed on the records to be received may be read from a set of Common 
Functions 18, 

1 0 After the list of operations to be performed on each of the record types is 
created (step 22), the DMC then starts a load monitor for each feed to be 
loaded (step 23). This load monitor effectively controls the load for that feed. 
The load monitor starts a number of load managers depending on the volume of 
data to be loaded, and on the number of different types of record to be 



O 1 5 processed, and each of these will cycle through the list of operations to be 



performed and execute each one on every record. Thus, in the present 
example, a CDR processing stream and a GSM processing stream are started, 

54 f 

yj with one or more load monitors for each stream. 

* 20 For each stream, the data record files for the particular type of record are 

f r? received (CDR fifes 24 and GSM files 25), and the operations to be performed 

PI within a feed are executed. In a typical scenario, the first operation 26, 27 to be 

carried out is to read a record from file and the last operation 28, 29 to be 
performed is to send (or otherwise render) the record to be loaded into an 
25 approriate database 32, of which only one is shown. Other operations, which 
are shown as step 30, 31 , may vary from translating particular fields contained 
in a record to enriching records with data retrieved from a reference table in the 
database. Looking up another table in the database and enriching a record is 
an example of how a feed might use one of the core services of the DMC, in this 
30 instance Reference Data Management. 

Once all operations have been performed for all feeds, statistics may be 
collected (step 33), for example the number of records loaded and the time 
taken for the load. 



35 



As shown in FIG. 3, the DMC provides a software framework 34 for generic 
processing of data records and a strategy for using the type-specific function 
libraries 19, 20 to implement functionality specific to a type of input record 24. 
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The framework 34 is a skeletal structure of software that is not tied to any 
specific format or type of record to be processed. The framework 34 provides a 
number of core common functions 35 (services) that may be used by any feed 
of data that is configured to be processed and loaded, Examples of these 
5 services 35 include a Message Logging facility 36, a Reference Data 

Management facility 37 and a Resource Management facility 38. These are all 
facilities that would be required in any typical scenario of processing records 
from a telecom network, 

10 In addition to these services the framework provides "function holders" 39 which 
are placeholders or interfaces for functions written by application developers. 
These functions each perform an operation on the data records and collections 
of functions for one type record (for example CDR) are collated in the type- 
specific function library, although this is not the only method possible. Therefore 
p 1 5 if a customer requires that a DMC processes only CDRs, the software used 

0 would be the DMC Framework and a CDR shared library. 

0 

Hi 

[fj The software architecture also allows for multiple types of record to be loaded at 

HI one time, thus forming a number of parallel load streams. For example if a 

4 20 customer requires that both CDRs and GSM CDRs be loaded, they would use 

j\, the DMC Framework 34, a type-specific library for CDRs 19 and another type- 

y specific library for GSM CDRs 20. The type-specific libraries have a number of 

CI type-specific functions, as described above and as shown in FIG, 3, for 

example, functions for reading, translating, enriching, correlating and loading 



i'l 25 into a database. 



In order for the framework 34 to be able to call separate functions for each 
defined operation it needs to be able to pass records through the framework so 
each operation can be invoked on each record. The DMC is able to "pass" 

30 records of multiple data formats through the framework by using the object 
oriented software engineering techniques of inheritance and polymorphism. 
The fields typically found in any type of record produced from signaling 
information on a telecommunication network are used to form a generalized 
record type known in the DMC as an Abstract Base Record 40. If a new type of 

35 data record is to be processed the Abstract Base Record 40 is specialized, that 
is a new record type, for example a CDR type 41, is derived from the Abstract 
Base Record 40 and it inherits the members and operations of this base type. 
Also, any virtual functions declared within the Abstract Base Record type can be 



30011271 



-7- 



defined within the derived type. For example Translate may be a virtual function 
of the Abstract Base Record but each record type derived may use its own 
definition. 



5 This generalization of all possible record types to a single base type means that 
the framework simply has to be able to handle records of one type, that is the 
Abstract Base Record, Due to the nature of object oriented software 
construction, this means that the framework has the ability to process records of 
any format on the condition they are derived from the base type. This enables 
10 the DMC architecture to be flexible and extensible. 

A further feature of the framework is the capability to buffer records during a 
particular operation. Buffering within the framework allows multiple records to 
M be collected at one point so an operation can be provided with a group of data 

p 1 5 records rather than just individual records. This is essential for operations such 

53 as the correlation of records where it may be necessary to buffer records for a 

•;;r! large period of time and then perform the correlation operation of tagging 

y\ records related to the same call, transaction or service. 

I 20 

y. The flexibility of the above described embodiment of the invention contrasts with 

y the known types of call data processor, in which the software is written 

0 specifically to process call data records (CDRs) and to load them into a 

database. This processing include several operations including translating the 
y. 25 CDRs from compressed binary format on disk to a format "loadable" into the 

database. As well as processing records, the system was responsible for 
managing the tablespace usage in the database including estimating how much 
space each toad required depending on the number of CDRs. Also, a facility 
was provided to translate certain fields in a CDR. Each of these facilities was 
30 written based on the fact that the system was used only for processing and 

loading CDRs and it was not possible to load or process any other sort of record 
without rewriting large amounts of the program source code. 

tt will be appreciated that although only one particular embodiment of the 
35 invention has been described in detail, various modifications and improvements 
can be made by a person skilled in the art without departing from the scope of 
the present invention. For example, alternative embodiments of the invention 
can be implemented as a computer program product for use with a computer 
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system, the computer program product being, for example, a series of computer 
instructions stored on a tangible data recording medium, such as a diskette, CD- 
ROM, ROM, or fixed disk, or embodied in a computer data signal, the signal 
being transmitted over a tangible medium or a wireless medium, for example 
microwave or infrared. The series of computer instructions can constitute all or 
part of the functionality described above, and can also be stored in any memory 
device, volatile or non-volatile, such as semiconductor, magnetic, optical or 
other memory device. 
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